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There is a story going around which is 
probably not true. At least, there is no 
official confirmation of it, and discrete 
inquiries have produced only denials. 
Nevertheless, after some investigation, we 
have decided to pass the item along and let 
you decide for yourself. 



The story concerns the new building, and a 
new design concept: the containerized office! 
The building is carefully arranged so that, 
when an organization needs to be moved, the 
offices are individually lifted out of posi- 
tion and then slid into their new location, 
without disturbing the contents of the office 
itself. All electrical connections, including 
phones and computer terminals, simply plug in 
as the module is fitted into place. 



We had a look at the new building and we 
must admit that the possibility is intriguing. 
Those two big cranes could do the job quite 
nicely, one removing the 'out' office and the 
other handling the r in f office. When a crisis 
developed and reorganization was critical, one 
could even imagine moving T on the fly 1 without 
disturbing the occupants . Each office could 
have prominently displayed "FASTEN YOUR SEAT 
BELTS" signs and the group chief could make a 
brief announcement over the intercom about the 
move and the ETA at the new location. 



From a certain angle, the new building 
looks a bit like a giant data base. Perhaps 
the entire "mover" system can be run from a 
remote terminal somewhere. If so, we trust it 
will be one of the faster ones. 






Contents of Cryptolog should not be repro- 
duced, or further disseminated outside the 
National Security Agency without the permis- 
sion of the Publisher . Inquiries regarding 
reproduction and dissemination should be 
directed to the Editor. 
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" t is practically impossible to teach 

I good programming to those who have 
, had a pr ior exposure to BASIC ; as 
potential programmers they are men- 
tally mutilated beyond hope of 
recognition. 11 

Now, now, before you come dashing up to my 
office to mutilate me please note that there 
are quotes around that statement . I did not 

say it . Actually it was made by professor 
Edsger W. Dijkstra, a Dutch physicist and com- 
puter scientist . One could infer from this 
that he didn't care too much for BASIC. 



Well, what is wrong with BASIC? Most of 
the personal computers have it . Most all new 
data systems people know it . You can get a 
personal computer to do almost anything you 
want by programming in it . Those of us who 
use them really aren't mentally mutilated, are 
we? Well, ARE WE?! 

PI 3 has been experimenting with powerful 
personal computers for a couple of years now 
in an effort to make the job of the analyst a 
little easier, and maybe even a bit more 
enjoyable. Our programming has been done in 
BASIC because BASIC came with the machines and 
there was no obvious reason to use anything 
else. 



As personal computers have become faster 
and ac quired more memory , and as other 
languages have become available, it seemed 
that the time had come to investigate some of 
them. For the past few months I have been 
looking into the use of Pascal on the IBM-PC, 
and would like to share some of my thoughts 
with you. 

First of all, it is necessary that you 
understand a very important difference between 
BASIC and Pascal . Bas ic , as it is purchased 
for most machines, is an "interpreted" 
language and Pascal is a "compiled" language. 

With an interpreted language, a programmer 
need only type the program into the computer, 
and give the command for the program to run. 
An interpreter then looks at the first state- 
ment, checks to be sure it makes sense, trans- 
lates it into code that is recognizable to the 
machine, and then executes it. This procedure 
continues until the program is completed. 

If the statement doesn't make sense, a mes- 
sage will appear on the screen telling the 
user that he has an incorrect statement and 
the program halts . The user can make the 
correction and restart the program. 
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So far so good , but how does this differ 
from Pascal? Well, when you are through writ- 
ing your Pascal program you type in a command 
calling the compiler. This compiler takes 
your entire program and attempts to translate 
it into a machine recognizable form. When the 
translation is complete, you may then run the 
program. On the IBM-PC compilation of even a 
relatively small program can take as long as a 
few minutes. If there are errors, the program 
may , of course , not compile . 

The important thing to remember here is 
that as soon as you write your BASIC program 
you can make an attempt at running it. Pascal 
requires that you comp i le your program. When 
writing a new Pascal program you may very well 
attempt numerous compilations before you are 
in a position to try to run it. This can get 
very frustrating and may very well cause you 
to begin to feel the urge to fold, spindle, or 
otherwise mutilate your disk — or maybe even 
the computer itself. 

In general , a correctly written compiled 
program will run noticeably faster than an 
interpreted program but, when you are actually 
doing the writing, it is more productive to be 
using an interpreted language. 

So, why Pascal? Well, if you are writing a 
program that you very well know might be used 
once or twice at most, then you clearly don't 
want to use Pascal . You may spend too much 
time trying to compile it. If, on the other 
hand, you were asked to write a program that 
will probab ly be used for years and will, of 
course, need to be maintained, then Pascal 
would be a good choice. 




A few examples will illustrate my point. 
Suppose you were asked to write a program that 
would store in a personnel file the names and 
addresses of the people in your office. Sup- 
pose you want to allow 20 characters for the 
name, 14 for the address which could contain 4 
digits for the street number and 10 for the 
street name, 10 characters for the city, 2 for 
the state, 5 for the ZIP code, and 7 for the 
phone number, for a total of 58 characters. 



In BASIC, variable names can only be two 
characters long so you would probably use a 
string PE$ (for personnel) which would be 58 
bytes long. Into this string you could place 
a NA$ for name, AD$ for address, SN$ for 
street name, CI$ for city, ST$ for state, ZI$ 
for ZIP and PH$ for phone. (BASIC requires a 
in the names of character strings.) When 
you concatenate these strings, you get your 
record . 

In this BASIC program you naturally would 
write some error-checking code to be sure that 
the user did not put in more than two charac- 
ters for the state name, seven for the phone 
number, 10 for the city, etc. 

Now, a year or two goes by and someone 
decides that the address should have room for 
at least 5 digits , the phone 10 digits (you 
want to show the area code), and the name 15 
characters. You must go through your BASIC 
program and try to remember which variables 
you used for name , phone , etc . It may be 
obvious now that PH$ must stand for phone, but 
a year from now when you are asked to change 
the telephone number length, are you going to 
remember that TELEphone (TE$ ?) this year was 
phone (PH$) last year? Maybe not. What about 
PE$ ? What is the new field length? 

Pascal will make it more difficult for you 
to confuse yourself . Pascal requires that ail 
data types, such as the string of characters 
containing the name, phone, etc , be identified 
at the beginning of the program, and that all 
of your constants , data types , and variables 
be declared very specif ical ly . The beginning 
of your Pascal program would look like this: 

TYPE 

PERSONNEL = 

RECORD 

name: PACKED ARRAY [1.. 20] of char; 
number: PACKED ARRAY [1.. 4] of integer; 
street: PACKED ARRAY [ 1 .. 1 0 ] of char; 
city: PACKED ARRAY[1..10] of char; 
state: PACKED ARRAY[1..2] of char; 
zip: PACKED ARRAY[1..5] of integer; 
phone: PACKED ARRAY [1.. 7] of integer 
END; 



r 
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A BASIC string is a Pascal "PACKED ARRAY". 



A year from now, if you wanted to allow 10 
digits in the phone number. . .no problem, you 
simply go to the TYPE declaration, look up 
"phone" and change the PACKED ARRAY from 7 to 
10 . 



That's it! If next year someone decides 
that information as to marital status is 
needed, you could add a new procedure 
"status", which would prompt the user with a 
yes/no question as to whether or not the indi- 
vidual is married. Into your RECORD area you 
could insert "status: boolean". No problem. 



OK , so Pascal does seem to allow easier 
maintenance of data; what else? Pascal allows 
a program to be broken up into separate pro- 
cedures. These individual procedures could 
each be programmed to do one simple task. A 
driver program would then sequent ial ly call 
the procedures . For example , in the above 
program, the driver might look like this: 

PROGRAM info; 

TYPE 

PERSONNEL = 

RECORD 

name: PACKED ARRAY [1.. 20] of char; 
number: PACKED ARRAY[l.,4] of integer; 
street: PACKED ARRAY [ 1 .. 10] of char; 
city: PACKED ARRAY[1..10] of char; 
state: PACKED ARRAY[1..2] of char; 
zip: PACKED ARRAY[1..5] of integer: 
phone: PACKED ARRAY [1.. 7] of integer 
END; 



BEGIN; 

get name; 
get__ad dress ; 
get_phone 
END. 



The procedure get_name would prompt the 
user to type in the person's name and would 
then store it in the PACKED ARRAY 'name'. The 
other procedures would do similar small tasks. 




In BASIC you would have to figure out a 
location in your program to insert the status 
information. What variables do you use? ST$ 
sounds good — or did you use that for state? 
You had better be careful. If you were writ- 
ing in BASIC you didn't declare your variables 
anywhere; you simply started using them. In 
contrast, the variable names in Pascal can be 
meaningful and the ones used in the procedure 
get_phone, for example, do not affect the ones 
in get_address. You can use the same names if 
you want . 



Pascal is not very forgiving. You MUST 
introduce all of your variables , constants , 
etc . at the beginning of the program. BASIC 
does not require this and unless a user is 
very careful with his error-checking, he can 
more easily insert incorrect data into a BASIC 
program than he could into a Pascal one; or a 
programmer might use the same variable name 
for two different variables. BASIC will 
easily allow this. 



Pascal tends to be self-documenting . The 
ind ividual procedures are generally quite 
short with the procedure and variable names 
very meaningful. Some versions of BASIC do 
allow variables of more that 2 characters but 
only the first 2 are recognized by the inter- 
preter ; therefore STate and STatus would be 
identical variables to the machine. So, the 
get_address procedure might put MD for Mary- 
land in the variable that you are calling 
State and then the Status procedure might 
modify that exact same variable to 'yes' or 
’no 1 . 



This could put the programmer into a bewil- 
dered status, or a state of confusion. 



It is for the above reasons that those of 
you who are using personal computers should 
consider using Pascal. 



Remember , you do not want to become men- 
tally mutilated! 
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S ensitivity markings, including Com- 
partment/Category and Classifica- 
tion/Caveat labels, often seem to be 
confused with one another, as well 
(U) as with the slew of acronyms and 
buzz words that proliferate in the everyday 
jargon here at the National Security Agency* 
Some of this confusion, such as the confusion 
between SI (Special Intelligence) and SCI 
(Special Compartmented Information) for exam- 
ple, does not necessarily pose an enormous 
problem for most NSA employees since many jobs 
here do not require a knowledge of the dis- 
tinction between these particular abbrevia- 
tions* For the employees of the newly esta- 
blished DoD Computer Security Center (DoDCSC), 
however, such distinctions are not trivial. 



(U) Specifically, the C2 organization 
(Office of Applications Systems Evaluations 
within the DoDCSC) is directly involved with 
the formal evaluations of both operational and 
developmental computer systems , inside and 
outside the NSA environment* The C21 division 
is responsible for providing ADP security gui- 
dance during the development of systems, while 
C22 evaluates systems that are about to become 
operational or are already fully operational* 

Generally speaking, computer processing 
systems are evaluated in different ways 
depending on the users and the types of infor- 



mation that pass through the system during its 
operational existence* Typically, any intel- 
ligence processing system may be described as 
operating in one of several modes, as defined 
by the Director of Central Intelligence Direc- 
tive (DC ID) Security Policy on Intelligence 
Information in Automated Systems and Networks 
(formerly DCID 1/16), which establishes policy 
for computer security in the Intelligence Com- 
munity. The most stringent category of ADP 
security is that of Compartmented Mode. 



SCI may be processed and/or stored in an 
ADP system operating in the Compart- 
mented Mode; that is, the system is pro- 
cessing two or more types of SCI, or any 
one type of SCI with other than SCI, and 
system access is secured to at least the 
TOP SECRET level, but all system users 
need not necessarily be formally author- 
ized access to all types of SCI being 
processed and/or stored in the system, 
(p. 5, paragraph II.2.CG)) 



(U) A recent C22 evaluation dealt with a 
computer system that is considering placing 
GAMMA-controlled information in an existing 
system data base- Thus , GAMMA had to be 
defined using the terms that were thought to 
be appropriate so that the system in question 
could be properly mapped into one of the 
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